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We view channels as the main form of resources in a message-passing programming paradigm. These 
channels need to be carefully managed in settings where resources are scarce. To study this problem, 
we extend the pi-calculus with primitives for channel allocation and deallocation and allow channels 
to be reused to communicate values of different types. Inevitably, the added expressiveness increases 
the possibilities for runtime errors. We define a substructural type system which combines uniqueness 
typing and affine typing to reject these ill-behaved programs. 

1 Introduction 

Message-passing concurrency is a programming paradigm whereby shared memory is prohibited and 
process interaction is limited to explicit message communication. This concurrency paradigm forms the 
basis for a number of process calculi such as the pi-calculus |fI51 and has been adopted by programming 
languages such as the actor based language Erlang [3]. 

Message-passing concurrency often abstracts away from resource management and programs written 
at this abstraction level exhibit poor resource awareness. In this paper we study ways of improving this 
shortcoming. Specifically, we develop a statically typed extension of the pi-calculus in which resources, 
i.e. channels, can be reused at varying types and unwanted resources can be safely deallocated. 

Idiomatic pi-calculus processes are often characterized by wasteful use-once-throw-away channels 
irT5l[T4ll . Consider the following two pi-calculus process definitions 



TIMES RV defines a server that repeatedly waits on a channel named getTime to dynamically receive a 
channel name, represented by the bound variable x, and then replies with the current time on x. DATES RV 
is a similar service which returns the current date. An idiomatic pi-calculus client definition is 

CLlENTo = (vret\ ) getTime\{ret\ ).ret\!{y hr ,y min ). (vret 2 ) getDate ! (ret 2 ) ■ret 2 '?(zyear,z m on , Zday) ■ P 

CLlENTo uses two distinct channels ret\ and ret 2 as return channels to query the time and date servers, 
and then continues as process P with the values obtained. These return channels are scoped (private), to 
preclude interference from other clients concurrently querying the servers. 

From a resource management perspective it makes pragmatic sense to try and reduce the number of 
channels used and use one channel to communicate with both the time server and the date server. 

CLIENT i = (vret) getTime ! (ret) .retl(y hr ,y min ) . getDate ! (ret) .ref.(z year , z m0 n , Zday) ■ P 
*This research was supported by SFI project SFI 06 IN. 1 1898. 



timeSrv = recX .getTimelx.x\(hr , rain) X 
dateSrv = recX .getDatelx.x\(year ,mon, day) .X 



M. Florido and I. Mackie (Eds.): First International 

Workshop on Linearity (LINEARITY 2009) 

EPTCS 22, 2010, pp. 26-1371 doi: 10.4204/EPTCS ^231 



© E. de Vries, A. Francalanza and M. Hennessy 



E. de Vries, A. Francalanza and M. Hennessy 



27 



From a typing perspective, this reuse of the same channel entails strong update on the channel: that is, 
reuse of a channel to communicate values of different types. Strong update must be carefully controlled; 
for instance, an attempt to use one channel to communicate with both servers in parallel is unsafe: 

CLlENT err = (vret) {getTime\(ret).retl(y hn y min ).P l \\ getDate\(ret).ret7(zy ear ,z m on,Zday)-Pz) 

Standard pi-calculus type systems accept only CLIENT^ and rule out both CLIENT i and CLlENT err . How- 
ever, CLIENT^ is safe because the communication with the date server happens strictly after the commu- 
nication with the time server, and also because the time server will only use the return channel once. 

Adequate resource management also requires precise descriptions of when resources are allocated 
and existing ones are disposed. The characteristic scoping construct (vc)P is unfit for this purpose 
and should be used only as a bookkeeping construct delineating name scoping (which evolves during 
computation through scope extrusion) . One reason against such an interpretation is the structural rule 

(SSCP) P=(vc)P whenever c £ fn(P) 

whose symmetric nature would entail implicit garbage collection of channels, but also the possibility 
of unfettered spurious channel allocations. Another reason against this interpretation is the fact that the 
pi-calculus semantics does not specify whether, in a process such as CLlENTo, channel reti is allocated 
before or after the input on ret\. This problem becomes more acute when scoping occurs inside recursive 
definitions. We address this shortcoming by introducing an explicit allocation construct alloc(x).P. When 
the allocation is executed, a new channel c is created at runtime and the alloc(;c).P changes to (vc)P{ c /x}. 
Dually, we also extend the calculus with an explicit deallocation operator freec.P. We can then rewrite 
the client as: 

CLIENT 2 = alloc (x) .getTime ! (x) .x?(y hr ,y min ) .getDate ! (x) .x7(z yea r , z mon , Zday ) -freex.P 

Inevitably, the added expressiveness of this extended pi-calculus increases the possibilities for runtime 
errors like value mismatch during communication and usage of channels which have been deallocated. 

We define a type system which rejects processes that are unsafe; the type system combines unique- 
ness typing [4] and affine typing fl4l . while permitting value coercion across these modes through sub- 
typing. Uniqueness typing gives us global guarantees, simplifying local reasoning when typing both 
strong updates and safe deallocations. Uniqueness typing can be seen as dual to affine typing [10], and 
we make essential use of this duality to allow uniqueness to be temporarily violated. 

2 The Resource Pi- Calculus 

Fig. Q] shows the syntax for the resource pi-calculus. The language is the standard pi-calculus extended 
with primitives for explicit channel allocation and deallocation; moreover, channel scoping records 
whether a channel is allocated (T) or deallocated (_L). The syntax assumes two separate denumerable sets 
of channel names c,d S NAMES and variables x, y € VARS, and lets identifiers u,v£ NAMES U Vars 
range over both. The input and channel allocation constructs are binders for variables x and x resp., 
whereas scoping is a binder for names (i.e., c). The syntax also assumes a denumerable set of process 
variables X,Y € PVARS which are bound by the recursion construct. 

Channels are stateful (allocated, T, or deallocated, _L) and process semantics is defined over con- 
figurations, (o,P) where a € £ : Chans — {T,_L} describes the state of the free channels in P, and 
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P,Q 



u\v.P 
nil 

recX.P 

P\\Q 
alloc(x).P 



(output) 
(nil) 

(recursion) 

(parallel) 

(allocate) 



ulx.P 

if w = vthen,P else Q 
X 

(vc:s)P 
freew.P 



(input) 
(match) 

(process variable) 
(stateful scoping) 
(deallocate) 



Figure 1 : Polyadic resource pi-calculus syntax 



stateful scoping (vc:s)P describes the state of scoped channels. A tuple (o,P) is a configuration when- 
ever fn(P) C dom(a) and is denoted as a oP. We say that a configuration a >P is closed whenever P 
does not have any free variables. Fig. [2] defines contexts over configuration where ^[aoP] denotes the 
application of a context ^ to a configuration o>P. In the case where a context scopes a name c the 
definition extracts the state relating to c from a and associates it with c. For example, 

(Vc)[c:T,d:T>c\d]=d:T>(vc:T)c\d 

The reduction relation is defined as the least contextual relation over closed configurations satisfy- 
ing the rules in Fig. [2 using a standard pi-calculus structural equivalence relation (=). Communication 
(rCom) requires the communicating channel to be allocated. Allocation (rAll) creates a private al- 
located channel and substitutes it for the bound variable of the allocation construct in the continuation; 
the condition c dom(a) ensures that c is fresh in P. Deallocation (rFree) is the only construct that 
changes the visible state of a configuration, <r. 

Fig.|2]also defines error reductions as the least contextual relation satisfying the rules for — K These 
rules capture errors resulting from arity mismatch and attempts to communicate on deallocated channels. 
In particular arity mismatch can come from unconstrained use of strong updates such as in the case of 
CLlENT err in the Introduction. 



3 Type System 

3.1 The typing relation 

The type language is defined in Figure [3] and the typing rules are given in Figure @] The typing relation 
over processes takes the usual shape: rhP read as "P is well-typed under the typing assumptions in 
T". Typing environments are multisets of pairs of identifiers and types; we do not a priori make the 
assumption that they are partial functions (Section 1331 ) . This relation is extended to configurations as 

rih ot>p 

by requiring that the process is well-typed in T, all channels in T are allocated in a, and T is a partial 
function (i.e., for every identifier in P there is exactly one typing assumption in T). 

3.2 The type language 

The core type of our system is the channel type, {T^] a , consisting of an n-aiy tuple of types describing 
the values carried over the channel and an attribute a which gives usage information about the channel 
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Contexts 

#»= [_] | tf\\p | p\\tf | (y c yg 

[o>P] = o>P 
1f[o>P]\\Q = o'>(P'\\Q) if ^[a>P] = c't>P' 



Q\\tf[ot>P] =g'>(Q\\P') if ^[o>P] = o't>P' 

def 



(vc)tf[e>P] =o't>{vc:s)P' if tf[o>P] = o',c:s>P' 
Reduction Rules 

(7(c) = T 

rCom RREC 



o>c\b\\clx.P — >G>P{ b /x} ' o>recX.P — > c>P{ recXP /x} 

c + d 

rThen RELSE 



a> if c = c then/ 5 else Q — > o>P a>if c = dther\P else g — ► aog 
c ^ dom(a) 

; / r ; 7T RAll rFree 

CT>alloc(*).P — > a>(vc:T)(P{ c /x}) <y,c:T> freec.P — > o,c:±>P 

P = P' o>P' — >o>Q' Q' = Q 



rStr 



o>P — > o>Q 

Error Reduction Rules 



1^1*1 A <*{c) = ± n °{c) = JL a>e ^ 

EATY ^EOUT err ElN = ESTR 



a>c\d.P\\clx.Q^ " o>c\d.P-^> o>clx.Q^ a: /' ' 

i 

Figure 2: Contexts, Reduction Rules and Error Predicates 



.■=>.. , a ::= 1 (affine) 

roc roceTs ! 1 W ( unrestricted ) 

proc (process; | ^ ^ (unique after i steps, i G N) 



Figure 3: Type language 
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(a channel is used when communication takes place across the channel). This attribute can take one of 
three forms: 

• A channel of type is an unrestricted channel; such type assumptions correspond to type 
assumptions of the form [T ] in non-substructural type systems. 

• A channel of type [T^] 1 is affine, and comes with an obligation: it can be used at most once. 

• A channel of type [T](*> ! ) comes with a guarantee that it is unique after i actions; we abbreviate 
the type [T]^ ' of channels that are unique now to [T]\ Unique channels can be used to describe 
instances where only one process has access to (owns) a channel. Accordingly, strong update and 
deallocation is safe for unique channels. 

3.3 Structural rules 

Since the type system is substructural, usage of type assumptions must be carefully controlled, and the 
logical rules do not allow to use an assumption more than once. Operations on the typing environment 
are described separately by the structural rules of Fig. |4] Although the subtyping relation is novel because 
it combines uniqueness subtyping (SUNQ) with affine subtyping (sAff) making them dual with respect 
to unrestricted types, the subtyping and weakening structural rules are standard. 

Rule tCon contracts an assumption of the form u : T, as long as T can be split as Ti and T2. 
Unrestricted assumptions can be split arbitrarily (pUnr and PPROC); affine assumptions cannot be split 
at all. An assumption u: [T] # about a unique channel can be split as an affine assumption u : [T] 1 and 
an assumption about a channel that is unique after one action u : [T]^' 1 ) — an action using the latter 
assumption must be coupled with a co-action on the affine channel, and since the affine assumption can 
only be used once it is sound to assume that the channel is unique again after the action has happened. 
More generally, a channel which is unique after i actions can be split into an affine assumption and a 
channel which is unique after (i+ 1) actions, and splitting is defined in such a way that the number of 
affine assumptions for a channel never exceeds the index i of the corresponding unique assumption. 

In particular when the index is no other assumptions about that channel can exist in the typing 
environment. This means that if a process can be typed using a unique assumption for a channel, no 
other process has access to that channel. The last structural rule, tRev, makes use of this fact to allow 
strong updates ("revision") to channels as long as they are unique. 

3.4 Logical rules 

The rules for input and output (tOut and TlN) decrement the attribute of the channel, i.e., they count 
usage. This operation is denoted by T,c: [T]"~' in Fig. [4] and states that affine assumptions can only be 
used once, unrestricted assumptions can be used an arbitrary number of types, and if a channel is unique 
after i+ 1 actions, then it will be unique after i actions once the action has been performed. 

Moreover, TOUT requires separate typing assumptions for each of the channels that are sent. The 
attributes on these channels are not decremented, because no action has been performed on them; instead, 
the corresponding assumptions are handed over to the parallel process receiving the message. If the 
sending process wants to use any of these channels in its continuation (P) it must split the corresponding 
assumptions first. 

Recursive processes must be typed in an environment that contains only unrestricted channels (tRec). 
This is reasonable since recursion can be used to define processes with an unbounded number of parallel 
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Logical rules 

1 A TIN ' 1 L=* TOUT TPAR 

r,u:[T] a \-uix.p r,u:[TY,^7thu\v.p r u r 2 \- P\\Q 

u ,ver rhP r+e r ffl ,x: P rochP 

TlF tREC TVAR 

rhif M = vthenPelseg r ffl h recX.P X.prochX 

r,x:[f]'\-p r+p 

: . tAll =? tFree tNil 

rhalloc(x)./ 5 "~ i>:[T]*hfree M .P H nil 

r,c:ThP r+p 

tRst! tRst2 



r+(vc:T)P r+(vc:+)P 
where r ffl is an environment containing only unrestricted assumptions and all bound variables are fresh. 
Structural rules 

' ^ l ° 1 2 i ,w. 1 1 . 



T = T,oT 2 r, M :Ti, M :T 2 r-P T+P 



tCon TWEAK 



r,ii:ThP F>:ThP 

r>:T 2 hP T X <:T 2 r,u:[t 2 ]'hP 

tSub L 4 tRev 

r, M :T!hP r>:[Ti] , l-P 

Typing configurations 

Vc € dom(r).<j(c) = T ThP T is a partial map 

tConf 

TlhaoP 

Channel usage 



r,c:[f] 



a-1 M 



if a = 1 
r,c:[f] fi) ifa = « 
r,c:[f]M if a =(.,i + l) 



Type splitting 

■rg ^ ^— pUnr pProc -4 , ., -v , — t pUnq 

[Y] 65 = [T] £0 o[T] ft5 proc = procoproc [T](».0 = [T] 1 o [T] (, ' ,+1) 

Subtyping 

ai <: a 2 

SlNDX SUNQ sAFF — STYP 

<:(•,/ + 1) (•,/ + !) <:fi> co <: 1 [T] a > <: [Tf 2 

I I 



Figure 4: Typing rules 
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uses of some channel. Nevertheless, it is not as serious a restriction as it may seem ,as recursive pro- 
cesses can still send, receive and allocate unique channels. For instance, the following process models 
an "infinite heap" that keeps allocating new channels and sends them across a channel heap : [[T]*] ft) : 

infHeap = recX.alloc(jc). heap\x.X 

As expected, allocation introduces unique channels (tAlloc) and only unique channels can be deallo- 
cated (tFree). Finally, a typing assumption is introduced in the typing environment for locally scoped 
names only if the corresponding channel is allocated (TRSTl and RRST2). 



3.5 Consistency 

When we take a bird's eye-view of a system, every channel has exactly one type. In the definition of 
r lh G>P, we therefore restrict the environment to have at most one assumption about every channel: 
we require that T is a partial function. Consequently, we state type safety and subject reduction lemmas 
with respect to environments that are partial functions. 

Nevertheless, when two processes both need a typing assumption relating to the same channel c, 
there need to be two separate assumptions in the typing environment (cf. tPar in Fig. 0]). These two 
assumptions need not be identical; for example, an assumption c : []" can be split as two assumptions 

A consistent environment is defined to be an environment that can be obtained by applying any of the 
structural rules (contraction, weakening, subtyping or revision) from an environment which is a partial 
function. It follows that any process that can be typed in a consistent environment can also be typed in a 
environment that is a partial function. The reader may therefore wonder why we do not restrict the typing 
relation to partial functions. It turns out that even if a process can be typed in a consistent environment, 
some of its subprocesses might have to be typed in an inconsistent environment. As an example, consider 
the typing derivation 

a:[[] l } a> ,u:[}',x: [} l h freei* || a\x 

TlN 



a:[[\ x ] a ,u:[p l \x: []' h k?(). (freew ||abt 

tOut tIn 

a:[[] 1 ] a) , M :[] 1 h alu a: [[] 1 ] a >: D (,,1) h alx.ul{). (freea ||a!x) 
tPar 

a:[D 1 ] ffl .a:[D 1 r.«:D 1 .«:D ( *' 1) H a!w (freew ||a!x) 

: tCon (twice) 

a: [Q r.a: []* ^ a\u \\ alx.ulQ. (freew \\a\x) 

This is a valid typing derivation, and moreover the typing environment used at every step is consistent. 
But now consider what happens after this process takes a reduction step: 

u: \]',u : 11 r- freew \\a\u 

TlN 



h m?(). (freew || a\u) 

I ("ON 



w: []* h k?(). (free^ \\a\u) 

The tail of this process looks suspicious as it attempts to free u while simultaneously sending it on a. 
Indeed, freew \\a\u can only be typed in an inconsistent environment u : []' ,u : [J 1 . Nevertheless, the fact 
that this process is typeable is not a violation of type safety. The assumption u:[]' tells us that there are 
no processes that output on u so that the input on u is blocked: the tail of the process will never execute. 
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Thus, when an environment 



r,c:[T]V:[f] 
(e.g., u: [jf*' 1 ',^ : [J 1 ) is consistent, it may be the case that 



a' 




c:[T] 



(e.g., u: \\',u : f] 1 ) is inconsistent: this means that the tails of input or output processes may have to be 
typed under inconsistent environments, even when the larger process is typed in a consistent environment. 

However, communication in the pi-calculus provides synchronization points: when a communication 
happens, two processes will both start executing their tail processes. The following lemma says that if this 
happens, the resulting overall system (of both processes) is still typeable in a consistent environment; in 
fact, both must be derivable from the same partial function. This lemma is crucial in the subject reduction 
proof. 

Lemma 1. Let T,u: [T] a ' ,u: [T] a2 be a consistent environment, i.e., derivable from a partial function V 
by applying structural rules. Then T,u: [T] a '~ 1 ,M: [T] a2_1 is derivable from the same environment V, 
and is therefore consistent. 

3.6 Soundness 

We prove soundness of the type system in the usual way. 
Theorem 2 (Type safety). IfT Ih a >P then P ^ err . 

Theorem 3 (Subject reduction). IfT Ih ct>P and ct>P — > c't>P' then there exists a environment T' such 
thatVh a'>P f . 

Taken together these two theorems imply that a well-typed process will not have any runtime errors. The 
proofs of these theorems can be found in the accompanying technical appendix I2T1 . 

3.7 Examples 

The systems CLIENT, || timeSrv || DATeSrv for i £ {0, 1,2} can all be typed in our type system, whereas 
CLlENT err is rejected because type splitting enforces a common object type (cf. pUnr, pUnq in Fig. [4]) 
For convenience, we here recall CLIENT2 and consider how it is typed, assuming x is not free in P: 

CLIENT2 = alloc(jc) .getTime ! (x) .x?(y hr ,y min ) .getDate ! (x) .xl(z yea r , z mon , Zday)-^eex.P 

Assuming an environment with getTime: [[Ti,T 2 ] 1 ] ffl and getDate: [[T 3 ,T 4 ,T 5 ] 1 ]' B , CLIENT 2 types as 
follows. Rule tAll assigns the unique type [Ti,T2]* to variable x and the structural rule tCon then 
splits this unique assumption in two using pUnq. Rule TOUT uses the affine assumption for x for the 
output argument and the unique-after-one assumption to type the continuation. Rule TlN restores the 
uniqueness of x for the continuation of the input after decrementing the uniqueness index, at which point 
tRev is applied to change the object type of x from pairs of integers (for time) to triples of integers (for 
dates). The pattern of applying tCon, tOut and TlN repeats, at which point x is unique again and can 
be safely deallocated by tFree. 

Uniqueness allows us to typecheck a third client variation manifesting (explicit) ownership transfer. 
Rather than allocating a new channel, CLIENT3 requests a channel from a heap of channels and returns 
the channel to the heap when it no longer needs it, thereby reusing channels across clients. 

CLIENT3 = heap lx. getTime ! (x) .xl{y hr , y min ) .getDate ! (x) .x? (z year , z mon , Zday ) -heap Ix.P 
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With the assumption heap :[{T}'] (0 typing the system below is analogous to the previous client typings. 

CLIENT3 1| CLIENT3 1| CLIENT3 1| timeSrv II dateSrv II (vc)heap !(c) (1) 

In CLIENT2 and CLIENT3, substituting xlQ.Q for P makes the clients unsafe (they perform resp. 
deallocated-channel usage and mismatching communication). Both clients would be rejected by the type 
system because the use of x in x\().Q requires a split for the assumption of x, and it is not possible to 
split any assumption into a unique assumption and any other assumption. 

Finally, system (Q~|) above can be safely extended with processes such as CLIENT4 which uses unique 
channels obtained from the heap in unrestricted fashion. Our type system accepts CLIENT4 by applying 
subtyping from unique to unrestricted on the channel x obtained from heap. 

CLIENT4 = heaplx.recX .(getTimel (x) .xltyhr ,y min ) .P \\X) 

4 Related Work 

The literature on using substructural logics to support destructive or strong updates is huge and we can 
give but a brief overview here. More in-depth discussions can be found in ll20l[T7l . 

Resources and pi-calculus Resource usage in a pi-calculus extension is studied in lfl9l but it differs 
from our work in many respects. For a start, their scoping construct assumes an allocation seman- 
tics while we tease scoping and allocation apart as separate constructs. The resource reclamation 
construct in |fl9l is at a higher level of abstraction than free c.,P, and acts more like a "resource 
finaliser" leading to garbage collection. Resource reclamation is implicit in [ 19 ], permitting differ- 
ent garbage collection policies for the same program whereas in the resource pi-calculus resource 
reclamation is explicit and fixed for every program. The main difference however concerns the 
aim of the type systems: our type system ensures safe channel deallocation and reuse; the type 
system in [ 19] statically determines an upper bound for the number of resources used by a process 
and does not use substructural typing. 

Linearity versus Uniqueness In the absence of subtyping, affine typing and uniqueness typing coincide 
but when subtyping is introduced they can be considered dual ifTOl . For linear typing, the subtyping 
relation allows coercing non-linear assumptions into a linear assumptions, i.e., \U — > U, but for 
uniqueness typing, the subtyping relation permits coercing unique assumptions into non-unique 
assumptions. Correspondingly, the interpretation is different: linearity (resp. affinity) is a local 
obligation that a channel must be used exactly (resp. at most) once, while uniqueness is a global 
guarantee that no other processes have access to the channel. Combining both subtyping relations 
as we have done in this paper appears to be novel. The usefulness of the subtyping relation for 
affine or linear typing is well-known (e.g., see lfl2l ): subtyping for unique assumptions allows to 
"forget" the uniqueness guarantee; CLIENT4 above shows one scenario where this might be useful. 

Linearity in functional programming In pure functional programming languages, data structures are 
always persistent and destructive updates are not supported: mapping a function / across a list 
[jci, . . . ,x n ] yields a new list \fx\ x n ], leaving the old list intact. However, destructive updates 
cannot always be avoided (e.g., when modelling system I/O flj]) and are sometimes required for 
efficiency (e.g., updating arrays). Substructural type systems can be used to support destructive 
update without losing referential transparency: destructive updates are only allowed on terms that 
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are not shared. Both uniqueness typing [4] and linear typing have been used for this purpose, 
although even some proponents of linear typing agree that the match is not perfect l23l Section 3]. 
In functional languages with side effects, substructural type systems have been used to support 
strong (type changing) updates. For instance, Ahmed et al. have applied a linear type system to 
support "strong" (type changing) updates to ML-style references in a setting with no subtyping. 

It has been recognized early on that it is useful to allow the uniqueness of an object to be tem- 
porarily violated. In functional languages, this typically takes the form of a sequential construct 
that allows a unique object (such as an array) to be regarded as non-unique to allow multiple 
non-destructive accesses (such as multiple reads) after which the uniqueness is recovered again. 
Wadler's let ! construct |[22l (or the equivalent Clean construct # ! ) and observer types [16] both 
fall into this category, and this approach has also been adopted by some non-functional languages 
where it is sometimes called borrowing It is however non-trivial to extend this approach to a 
concurrent setting with a partial order over execution steps; our approach can be regarded as one 
preliminary attempt to do so. 

Strong update in the presence of sharing There is substantial research on type systems that allow strong 
update even in the presence of sharing; the work on alias types and Vault Ifl"8ll24l l8l and on CQual 
l9l are notable examples of this. These type systems do explicit alias analysis by reflecting mem- 
ory locations at the type level through singleton types. This makes it possible to track within the 
type system that a strong (type changing) update to one variable changes the type of all its aliases. 
The interpretation of unique (or linear) in these systems is different: a unique reference (typically 
called a capability in this context) does not mean that there is only a single reference to the object, 
but rather that all its aliases are known. For non-unique reference not all aliases are known and so 
strong update is disallowed. 

These systems are developed for imperative languages. They are less useful for functional lan- 
guages because they cannot guarantee referential transparency, and they appear to be even less 
useful for concurrent languages: even if we track the effect of a strong update on a shared ob- 
ject on all its aliases, this is only useful if we know when the update happens. In an inherently 
non-deterministic language such as the pi-calculus this is usually hard to know before execution. 

Linearity in the pi-calculus Linear types for the pi-calculus were introduced by Kobayashi et al. lPT4l 
but do not employ any subtyping. Moreover, their system cannot be used as a basis for strong 
update or channel deallocation; although they split a bidirectional linear ("unique") channel into 
a linear input channel and a linear output channel (cf. Definition 2.3.1 for the type combination 
operator (+) ) these parts are never "collected" or "counted". The more refined type splitting op- 
eration we use in this paper, combined with the type decrement operation (which has no equivalent 
in their system) is key to make uniqueness useful for strong updates and deallocation. Our system 
can easily be extended to incorporate modalities but it does not rely on them; in our case, channel 
modalities are an orthogonal issue. 

Fractional permissions and permission accounting Boy land [6] was one of the first to consider split- 
ting permissions into fractional permissions which allow linearity or uniqueness to be temporarily 
violated. Thus, strong update is possible only with a full permission, whereas only passive access 
is permitted with a "fraction" of a permission. When all the fractions have been reassembled into 
one whole permission, strong update is once again possible. 

Boyland's suggestion has been taken up by Bornat et al. @, who introduce both fractional per- 
missions and "counting" permissions to separation logic. Despite of the fact that their model 
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of concurrency is shared-memory, their mechanism of permission splitting and counting is sur- 
prisingly similar to our treatment of unique assumptions. However, while their resource reading of 
semaphores targets implicit ownership-transfer, uniqueness typing allow us to reason about explicit 
ownership-transfer. Moreover, subtyping from unique to unrestricted types provides the flexibility 
of not counting assumptions whenever this is not required, simplifying reasoning for resources that 
are not deallocated or strongly updated. 

Session types Session types ifTTTl and types with CCS-like usage annotations lfl2l are used to describe 
channels which send objects of different types. However, these types give detailed information on 
how channels are used, which makes modular typing difficult. For example, the heap channel used 
by CLIENT3 cannot be given a type without knowing all the processes that use the heap. 

5 Conclusions and Future Work 

We have extended ideas from process calculi, substructural logics and permission counting to define a 
type system for a the pi-calculus extended with primitives for channel allocation and deallocation, where 
strong update and channel deallocation is deemed safe for unique channels. 

The purpose of our type system is not to ensure that every resource that is allocated will also be 
deallocated (i.e., the absence of memory leaks). This is difficult to track in a type system. For instance, 
consider 



Statically, it is hard to determine whether the third parallel process will eventually execute the free* 
operation. This is due to the fact that it can non-deterministically react with either the first or second 
parallel process and, should it react with the second process, it will block at d2^().freex. In order to reject 
this process as ill-typed, the type-system needs to detect potential deadlocks. This can be done lTT3"l . but 
requires a type system that is considerably more complicated than ours. We leave the responsibility to 
deallocate to the user, but guarantee that resources once deallocated will no longer be used. 

The simplicity of our type-system makes it easily extensible. For instance, one useful extension 
would be that of input/output modalities, which blend easily with the affine/unique duality. Presently, 
when a server process splits a channel c : [T]* into one channel of type [T](*> 2 ) and two channels of 
type [T] 1 to be given to two clients, the clients can potentially use this channel to communicate amongst 
themselves instead of the server. Modalities are a natural mechanism to preclude this from happening. 

We are currently investigating ways how uniqueness types can be used to refine existing equational 
theories, so as to be able to equate processes such as CLIENT 1 and CLlENTo- This will probably require 
us to establish a correspondence between uniqueness at the type level and restriction at the term level. 
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